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AR % de José Manuel Muñoz 


Funcionan las texturas 
procedurales de POV (parte 1 


os creadores de 
«POV» definen. en 
su libro “Raytra- 
cing 11”, la palabra 
textura como ”...la 
descripción del ma- 
terial con el que está hecha una figu- 
ra...” Y también indican que “Las tex- 
turas sólo afectan al aspecto superficial 
de los objetos y figuras y nunca a su 
forma real”. (Aunque este libro publi- 
cado por Anaya trata de la versión 2.2 
de <POV», los capítulos dedicados al 
tema de las texturas siguen siendo —al 
igual que la parte de referencia— muy 
útiles aunque no contemplan las nove- 


dades de la versión 3.0). Esto no impi- 
de que algunas texturas parezcan alte- 


Este modelo es una versión libre del caza Starfury de Babylon 5. 
Ha sido creado por Mark Kane y fue publicado en Pcmanía número 11. 


rar completamente la forma de los 
objetos. Como veremos a continua- 
ción, el lenguaje escénico de «POV» 
En el número anterior incluimos un pequeño dispone de un conjunto muy completo 
de sentencias para definir texturas. 
resumen sobre el tema de las texturas para que  Conestas sentencias podremos definir 
el color de las superficies, la forma en 
los Povmaníacos recién enganchados pudiesen que se ha de reflejar la luz. la transpa- 
rencia, la rugosidad, etc. Así, definien- 
utilizar las texturas incluidas en la librerías de do valores para todas estas propieda- 
des, podremos crear nuestras propias 
«POV». En esta ocasión, vamos a profundizar un texturas para simular agua, metales, 
madera, piedra, etc. 


poco más en este tema, de manera que 


Bloques de comandos 
nuestros lectores más recientes puedan crear La definición completa de una tex- 

tura se realiza en tres apartados bási- 
sus propias texturas procedurales. cos donde se definen todos los aspec- 


tos de la misma. Con las sentencias 


englobadas dentro del apartado “pig- : 


ment” definiremos el color o el mapa 
de colores de la textura. Con las sen- 
tencias incluidas dentro del apartado 
“normal” quedará definida la rugosidad 
(o falta de ella) de la superficie del ma- 


terial, y con las sentencias pertenecien- 


tes al apartado finish declararemos a 


Así, la definición b 


queda como sigue 
texture[ 


” 


dad es la que 
bloque pigment y € 


torio include, donde se definen dive 


sos bloques finish con diferentes tipos ¿ 
de acabado que posteriormente son : 
empleados en la definición de texturas E 
metálicas. Si echáis un vistazo a dicho E 
fichero observaréis muchas líneas pa- E 


recidas a la siguiente: 


Htdeclare T_Brass_1A = texture ([ pigment ( : 


P_Brass1 Pinish [ F_MetalA )) 


En esta línea se está definiendo una E 
nueva textura aprovechando dos bloques E 
ya definidos anteriormente: el pigmento . 
P_Brass] y el acabado F_MetalA. Al ver : 


esta línea quizá os preguntéis dónde es- 


ta el apartado “normal” y la respuesta , 


es que, al no haberlo escrito nosotros, 
«POV» ha incluido el bloque “normal” 


definido por defecto. Lo cierto es que : 
«POV» crea valores por defecto para 


Una variación sobre este tema radica : 


en la posibilidad de definir nuevas tex- 


turas tomando como base otras texturas  ¿ 


completas definidas anteriormente. 
Cuando sea este el caso deberemos es- 


cribir en primer lugar el identificador de 


la textura que nos va a servir como base 
y añadir después los apartados que sean 
convenientes. Veamos un ejemplo: 


Hideclare mia=texturel T_Brass_1 finishf : 


ambient 0.10 Y 


ras que emplean el acabado metálico 
F_MetalA, La primera (tpruebal ) inclu- 
ye este acabado directamente en su defi- 
nición y la segunda (tprueba2) lo tiene 
porque ha incluido a la textura anterior 
como base de su propia definición. 

En la escena obtenida al renderizar 
este fichero veremos dos esferas: en la 
de la izquierda hemos aplicado tprue- 
bal y en la segunda tprueba2. Como 
veréis. la esfera de la derecha muestra 
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también un acabado metálico similar al 
de la otra, pero exhibiendo unas tonali- 
dades más oscuras que se deben al 
cambio realizado en el valor ambient 
del apartado finish. 

Ahora veamos otro caso. Suponga- 
mos que realizamos un par de cambios 
en el ejemplo anterior. Añadiremos la 
siguiente línea antes de la declaración 
de la textura tprueba2: 
fdeclare acabado1=finishfambient 0.10) 

y luego cambiaremos un poco la de- 
claración de tprueba2: 

Htdeclare tprueba2=texture(tpruebal finish( 
acabado1H 

Al ver esto probablemente muchos 
pensaréis que obtendremos el mismo 
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) 


resultado anterior al renderizar. Pues 
bien, esto no será así sino que la esfera 
con la textura tprueba2 perderá su as- 
pecto metálico. Esto se debe a que al 
incluir el identificador “acabadol” 
dentro del bloque finish, todo el bloque 
finish definido para acabadol sustitu- 
ye al bloque finish de tprueba!. El nue- 
vo acabado de la esfera es distinto al 
anterior porque en el bloque acabado] 
POV ha añadido los valores que hay 
definidos por defecto para las senten- 
cias reservadas del apartado finish. Co- 
mo estos valores por defecto no coinci- 
den con los definidos para el bloque 
finish F_MetalA (en el fichero metals.inc), 
el resultado es diferente. 


Aplicando algo de turbulencia a la trama wood. 


Figura 1: “textura de la esfera de la deracha” 


Hdeclare mimapa2=color_map ([ 
[0.0 color rgb <1, O, 0>] 


[0.5 color rgb <1, 1, 0>] 
[1.0 colorrgb <1, O, 0>] 


fídeclare tprueba4=texture[pigmentiwood color_map(mimapa2]H) 


Resumiendo: al incluir un identifica- 
dor dentro de un apartado pigment, 
normal o finish, se emplearán todas las 
propiedades definidas anteriormente 
para ese identificador. (Naturalmente el 
tipo del identificador habrá de coincidir 
con el del apartado donde lo escriba- 
mos. No podemos meter un identifica- 
dor definido como pigment dentro de 
un bloque finish). Si, por el contrario, 
no ponemos ningún identificador y 
añadimos una sentencia nueva dentro 
de uno de los bloques de una textura ya 
definida, entonces la nueva propiedad 
se sumará a las que ya tuviera defini- 
das la textura en dicho bloque. 

Por último, debéis recordar siempre 
la ley de los bloques contenedores. Por 
ejemplo, en el caso siguiente: 
unionfobjectícabeza) 

objectínariz; 
objectíojo texture[tojoj) 
texture(colorpiel] 


la textura colorpiel se aplica en este 
caso sobre los objetos de la unión “ca- 
beza” y “nariz” mientras que la textura 
tojo se aplica sólo sobre el objeto 
“ojo”, que ignora a colorpiel al tener 
incluida su propia textura. Si en este 
ejemplo hubiésemos puesto también 
texturas dentro de los bloques de “ca- 
beza” y “nariz”, entonces colorpiel no 
se aplicaría sobre ningún objeto y su 
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Un experimento caprichoso 


cambiando el cólor normal asignado 


en la trama de colores del caza. 
. 
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inclusión sería superflua, aunque no 
generaría error alguno. 


Pigment 

Como ya hemos visto, la sentencia 
pigment se emplea para abrir un blo- 
que donde escribiremos las sentencias 
que definen el color o la trama de colo- 
res de la textura. Hay que recordar que 
pigment define el color propio de las 
superficies, el cual no es necesaria- 
mente el que veremos siempre al ren- 
derizar la escena. 

Si por ejemplo tenemos un objeto 
con un pigmento blanco e iluminamos 
la escena con una luz azul, el resultado 
será un objeto de apariencia azulada. 
Coro ya vimos en números anteriores 
podemos escribir cosas como: 
pigment[ White ) 

donde empleamos un color definido 


en el fichero colors.inc. Y también po- 
demos especificar un color directamen- 
te utilizando la sentencia RGB: 
pigmentirgb<1.1.1>) 

Todo esto nos servirá para especifi- 
car colores lisos, pero, por citar sólo 
dos casos, ¿cómo se generan las tramas 
de colores que pueden verse en las tex- 
turas de madera y 
mármol? La res- 
puesta es compleja 
y quizá por ello 
muchos povmanía- 
co no han profundi- 


«POV» (como woods,inc, stonesl.inc, 
textures.inc y otros). Sin embargo, si 
queremos crear nuestras propias textu- 
ras O al menos manipular las ya exis- 
tentes, estamos obligados a saber cómo 
funciona esto. 

Para empezar «POV>» dispone de una 
larga serie de sentencias como wood, 


Figura 2: “textura de la esfera de la derecha” 


fideclare mimapai=color_map [ 
color rgb <1, O, 0>] 
color rgb <1, O, 0>] 
color rgb <1, 1, 0>] 
color rgb <1, 1, 0>] 


tideclare tprueba3=texture[pigment(wood color_mapímimapa1]H 


[0.0 
zado en este tema, [0.5 
limitándose durante [0.5 
mucho tiempo a [1.0 
utilizar las excelen- ) 
tes texturas que vie- 
nen definidas en los 


archivos include de 


AN 


granite. marble y muchas otras más que 
generan tramas internas que se utilizan 
para alterar el color de las superficies. 
Estas tramas o patrones asignan valores 
que oscilan entre 0.0 y l-a cada punto 
3D de las superficies donde se aplican. 
Y con dichos valores se asigna a cada 
punto 3D un color tomado de una tabla 
de referencia de colores. El usuario pue- 
de definir su propia tabla de colores 
utlizando la sentencia color_map o bien 
puede emplear la tabla por defecto. Es- 
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llaves y se define con una lista de refe- 
rencias que debe cubrir los valores de 
intensidad de 0.0 a 1. Cada referencia 
se encierra entre corchetes y dentro de 
cada una se especifican primero el va- 
lor de intensidad y luego el color que 
deberá mapearse sobre las superficies 
en los puntos donde la trama tenga la 
intensidad de la referencia. En nuestro 
ejemplo el color para la intensidad O 
será el rojo. Posteriormente, el color se- 
rá amarillo en los puntos de intensidad 


anillos concéntricos paralelos al eje Z. 
Cuando esta t 
mapa de colores ha sido adecuadamen- 


ya se agita un poco y el 


te definido (lo cual no es el caso de 
nuestro ejemplo), el resultado es simi- 
lar al de los anillos concéntricos que 
pueden verse en la madera real. Por de- 
fecto, cada anillo está separado del si- 
guiente por una unidad de distancia. 
por lo que tendremos que emplear el 
comando scale para ajustar el tamaño 
en objetos cuyas dimensiones sean de- 


Dos ejemplos de aplicación de la trama brick. El cubo de la derecha también usa turbulencia. 


tas tablas o mapas de colores definen 
una lista de intervalos a los que se aso- 
cian colores. Para entender esto un po- 
co mejor, examinad el fichero de ejem- 
plo tprueba2.pov. En él hemos creado 
un par de texturas que usan la sentencia 
wood e incluyen un mapa de colores 
propio. Estas dos texturas se aplican 
sobre dos esferas. En la de la derecha 
hemos aplicado la textura que podéis 
ver en la Figura 1. 

En esta figura podéis ver la estructu- 
ra que se emplea para definir un mapa 
de colores. Este mapa se encierra entre 


0.5 y volverá a ser rojo en los puntos 
de intensidad 1.0. Seguramente ya os 
estaréis preguntando qué color se ma- 
peará en los puntos de intensidad inter- 
media entre dos referencias. Y la res- 
puesta está en que el color de esos 
puntos se calculará por interpolación li- 
neal de las dos referencias entre las que 
se hallen comprendidos. Así, por ejem- 
plo, el color de un punto de intensidad 
0.25, estará a medio camino entre el ro- 
jo y el amarillo. 

En cuanto a la palabra wood, crea 
una trama de intensidades que forma 


masiado grandes o demasiado peque- 
ñas para la trama. 

Por otro lado, puede ocurrir que por 
alguna razón nos interese que haya zo- 
nas de color liso como las que podéis 
ver en la otra esfera del ejemplo ante- 
rior, donde el color de los anillos pasa 
bruscamente de rojo a amarillo y vice- 
versa. Esto podemos conseguirlo utili- 
zando un mapa de colores como el em- 
pleado en dicha esfera y que podéis ver 
en la Figura 2. 

Para conseguir una zona lisa entre 
dos rangos de intensidad basta con in- 


dicar el mismo color en las dos referen- 
cias implicadas, con lo cual no se pro- 
duce interpolación. 

Ahora avancemos un poco más en 
este tema. Hemos dicho que wood ge- 
nera una trama que suele emplearse pa- 
ra crear texturas de madera pero, como 
acabamos de ver, los resultados que se 
obtienen con ella son excesivamente 
regulares. Hace falta algo más y la res- 
puesta está en las sentencias que 
«POV» ofrece para desorganizar y agi- 
tar las tramas. 


Turbulence 

Esta sentencia se emplea para indicar 
el grado de agitación que debe emplear- 
se sobre una trama aplicada a una su- 
perficie. Turbulence puede emplear co- 
mo parámetro un valor en flotante o un 
vector y los valores admitidos van des- 
de O (no hay ninguna turbulencia) a 1 
(máxima turbulencia). Cuando se em- 
plee un vector podremos especificar di- 
ferentes grados de turbulencia para cada 
eje espacial (no olvidéis que las tramas 
son tridimensionales y afectan a todo el 
volumen espacial del universo de 
«POV»). Así, por ejemplo, la sentencia: 
turbulence <0.2, 1, 0> 

genera algo de turbulencia a lo largo 
del eje X. un grado máximo de turbu- 


lencia en el eje Y, y ninguna turbulencia 
en el eje Z. (Nota: la sentencia turbu- 
lence se emplea para muchas cosas más 
aparte de para agitar las tramas de pig- 
mentación. Con turbulence podemos 
también agitar las normales de una su- 
perficie o añadir turbulencia a los halos 
o a la niebla). Si renderizáis el archivo 
de ejemplo trprueba4.pov podréis com- 
probar cómo afecta la turbulencia a las 
texturas wood explicadas en tprueba2. 
Turbulence emplea una función de 
ruido aleatorio llamada Dnoise que ge- 
nera una agitación de la trama siguien- 
do un número determinado de pasos 
que se indican con la sentencia “octa- 
ves”. El valor, por defecto, para octaves 
es de 6 y el tiempo de cálculo va au- 
mentando progresivamente con valores 
mayores. (Nota: el rango de valores per- 
mitido para octaves va de 1 a 10). La 
turbulencia va decreciendo paulatina- 
mente con cada nuevo paso u octava. 
Este decrecimiento se indica con la sen- 
tencia omega cuyo valor por defecto es 
de 0.5 (lo cual significa que cada nuevo 
paso tiene la mitad del tamaño del ante- 
rior). En cuanto al grado de aleatorie- 
dad relativa entre cada octava, éste se 
aplica según el valor que demos como 
parámetro a la sentencia lambda cuyo 
valor por defecto es de 2.0, lo que pro- 


Las propiedades de la textura de la esfera derecha han sido 
“heredadas” de la textura aplicada en la esfera izquierda. 


duce unos resultados bastante aleatorios. 


Nota: aunque predecir los resultados 
que se obtendrán con los valores dados 
a turbulence no es excesivamente difí- 
cil, sí que puede serlo intentar hacer lo 
propio con los valores dados a las sen- 
tencias octaves, omega y lambda. Aquí, 
como casi siempre, dependeremos de 
los experimentos propios para conse- 
guir el resultado deseado. 


Tipos de tramas 

Seguidamente vamos a incluir una 
pequeña lista donde se describen los pa- 
trones permitidos por «POV». Todas las 
tramas que generan estos patrones se 
aplican en el plano X-Y, a lo largo del 
eje Z y tienen su centro en las coorde- 
nadas <0,0,0>. (Nota importante: por 
eso el anillo más interno producido por 
wood arranca de esa posición. $1 quere- 
mos que dicho anillo resulte visible en 
objetos situados en otras posiciones ten- 
dremos que incluir una orden translate 
al final del bloque texture. Otra posibili- 
dad es crear el objeto en la posición don- 
de la aplicación de la textura nos resulta 
interesante y luego utilizar una orden 
translate al final del bloque del objeto). 
En cuanto a las sentencias turbulence, 
vctaves. omega y lambda suelen utili- 
zarse para alterar aunque hay excep- 
ciones— las tramas que generan las sen- 
tencias que detallamos a continuación: 

+ Agate: Con esta sentencia podre- 
mos crear tramas de pigmentación pa- 
recidas a las que pueden lograrse con 
marble, turbulenta y con manchas. Este 


patrón emplea una función de turbu- 
lencia propia cuya fuerza puede con- 
trolarse asignando un valor en flotante 
a la sentencia agate_turb. La sentencia 
turbulence también puede ser emplea- 
da (como octaves, omega y lambda), 
aunque Agate ya es lo suficientemente 
turbulenta de por sí. 

+ Bozo: Este patrón suele emplearse 
para crear nubes (añadiéndole un poco 
de turbulencia) ya que 
usa una función de 
ruido que genera unos 
resultados muy sua- 
ves gracias a que los 
puntos cercanos tie- 
nen valores de intensi- 
dad similares. 

* Brick: Esta sen- 
tencia sirve para gene- 
rar un patrón de ladri- 
llos. Su uso requiere 
el empleo de algunas 
sentencias adicionales 
y su sintaxis es: 
pigment ( 

brick color_1, color_2 


brick_size vector 


CómoO... 


emplea color_map aunque sí turbulence. 
Hallaréis un ejemplo en tprueba5.pov. 

+ Bumps: Esta sentencia. ideada para 
ser utilizada sólo desde el apartado nor- 
mal, genera una trama similar a la de las 
sentencias Bozo y spotted cuando se la 
utiliza desde el bloque de pigment. 

* Checker: Produce un patrón a cua- 
dros alternando dos colores. Suele ser 
empleado en tableros de ajedrez o en 


Pruebas de la trama de granito. 


suelos virtuales creados para compro- 
bar la corrección de las dimensiones de 
los objetos. Su sintaxis es: 

pigment[ checker pigment(color_1), pigment 


mortar flotante ícolor_2H 
) : Se necesita especificar dos colores pa- 
Aquí, color_1 indica el color del mor- cuadros 
tero que rodea a los ladrillos nd la onginidde estas 


que color_2 especificá 
propios ladrillos, 
indicar las dime 
llo. Los valores dados en c 
usan para especificar la lo 
da ladrillo a lo largo de 
igue a mortar in- 


grosor superio) 
dada a los 1 


pa de mortero que 


* Crackle: E 
ya que genera 


fue originalmente diseñado para ser em- 
pleado sólo en el apartado normal. (No 
sabemos cómo describir este patrón pe- 
ro parece adecuado para texturas metá- 
licas y para crear texturas que simulen 
superficies acuáticas o arenosas). 

» Gradient: Genera una trama de colo- 

res formada por capas que se extienden 
en la dirección del eje que se indica en el 
vector que le acompaña. Su sintaxis es: 
pigmentigradient vector] 
Por ejemplo, la línea 
plane (y,O pigment[ gradient 
<0,0,1> scale<10,10,10>] 
crea un plano de ban- 
das de líneas horizon- 
tales que se extienden 
hasta el horizonte, 
+ Granite: Esta senten- 
cia emplea una fun- 
ción fractal de ruido 
para generar un buen 
patrón de granito. Es- 
te tipo de trama es 
muy utilizada por los ficheros de tipo 
stones.inc para crear texturas de piedra. 
El buen acabado de estas texturas de- 
pende también del empleo de un buen 
mapa de colores y del uso de las sen- 
tencias de distorsión de patrones. 


5 > Esta sentencia es similar 
los de los ecker pero con la diferencia de que 


'a prismas hexagonales en lugar 
Por esta razón se requieren 
s.con lo que su sintaxis es: 


p,color_1, color_2, color_3) 


or ver una bue- 


crearemos algu 
les que sirvan co 


Informe Especial 


Galaxy.inc: un POV-IPAS 
para crear cuerpos celestes 


Presentamos un nuevo POV-IPAS capaz de 


generar magníficos paisajes estelares. Con 
Galaxy.inc de Chris Colefax —uno de los mejores 
creadores de efectos para «POV»— podremos 
crear fácilmente bellas escenas celestes en las 


que aparecerán Galaxias, nebulosas, 


agrupaciones de estrellas, cometas y meteoros. 


n el número 3 de 
Rendermanía pre- 
sentamos un método 
para crear paisajes 
estelares utilizando 
los halos de «POV», 
que ya fueron estudiados en el número 
2. La técnica empleada era muy senci- 
lla: se creaban uno o dos halos para ge- 
nerar nebulosas de fondo y luego se 
empleaban otro tipo de halos para 
crear las estrellas más grandes. Esta 
técnica, sin embargo, no estaba exenta 


XL 


de problemas, debidos a que el cúmu- 
lo estelar se creaba aleatoriamente 
dentro de un volumen espacial que 
también era compartido por los halos 
de las nebulosas. 

Esto a veces provocaba como resul- 
tado unos fallos visuales cuando los 
halos de las estrellas interferían con 
los de las nebulosas. La solución más 
simple hubiera sido, por supuesto, em- 
plear varios planos espaciales para los 
objetos. Podríamos, por ejemplo, ha- 
ber reservado el plano más cercano a 
la cámara para los objetos más próxi- 
mos como las naves espaciales y los 
campos de asteroides. Posteriormen- 
te, en orden de lejanía creciente, se 
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En definitiva, quizá algún día escri- 
bamos algún otro POV-IPAS (o include 
a secas, como empieza a llamarse a es- 
tos archivos en la red) para comprobar 
estas teorías. Por ahora nos limitare- 
mos a estudiar el paquete Galaxy,inc, 
cuya última versión publicó Colefax en 
febrero de este año y que podéis hallar 
en el CD-ROM 


Instalación 

Tenemos dos opciones de instala- 
ción: podemos descomprimir el ZIP 
que contiene al POV-IPAS dentro del 
directorio donde vayamos a crear las 
escenas o bien podemos hacer esto 
dentro del directorio include de nues- 


Aquí teneis tódos los objetos estelares que ha creado Colefax. 


podrían haber reservado volúmenes 
espaciales para las estrellas más cer- 
canas, las nebulosas, las estrellas más 
lejanas, etc. Todo esto no llegó a po- 
nerse en práctica pero previsiblemente 
también habría implicado problemas 
de realización, probablemente de ve- 
locidad de render. 
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tra instalación de «POV». Si optamos 
por esta última opción podremos em- 
plear los ficheros de Colefax desde 
cualquier directorio, simplemente in- 
dicando la ruta al directorio include 
con la opción de la línea de comandos 
“L” que ya explicamos en el número 
anterior. 


La filosofía de Galaxy.inc 

La filosofía del paquete de Colefax 
para generar paisajes estelares se basa 
en una idea radicalmente distinta a la 
que ya comentamos en el número 3. 
Sorprendentemente, en lugar de utili- 
zar halos, Colefax emplea simples dis- 
cos sobre los que genera diferentes 
texturas empleando tramas de pigmen- 
tación. Por supuesto, el tipo de trama 
empleada (granite, onion y otras) de- 
penderá —al igual que los mapas de co- 
lor usados— de cuáles sean los objetos 
celestes cuya apariencia se desea si- 
mular. (Nota: hay algunas excepcio- 
nes. El fondo de estrellas lejanas se 
crea sobre triángulos y las nebulosas 
estelares de fondo se crean sobre un 
objeto sky_sphere). 

Como recordaréis, los discos de 
«POV>» se crean con la sentencia disc 
del lenguaje escénico. Estos discos son 
infinitamente delgados y pueden tener 
opcionalmente un agujero en su centro, 
Colefax utiliza estos objetos para re- 
presentar estrellas, galaxias y otros ob- 
jetos, y el resultado es de un sorpren- 
dente realismo. Además, los discos se 
generan más rápidamente que los halos 
por lo que el método permite también 
al usuario ganar velocidad con respecto 
al método descrito más arriba. 

Colefax ha resuelto también fácil- 
mente el problema de la posible super- 
posición de objetos estelares con los 
modelos de primer plano (posibles na- 
ves espaciales). La solución de Colefax 
ha sido ”pegar” todos los objetos este- 
lares (estrellas, cometas, etc.) en la pa- 
red interna de una esfera gigante ima- 
ginaria (obteniendo así un modelo del 
universo muy parecido al de aquella 
antigua idea que sostenía que el firma- 
mento era una bóveda rígida en la que 


a 


e. 


las estrellas estaban colgadas). De esta 
manera el volumen interior de la esfera 
imaginaria —o esfera-toldo— puede re- 
servarse para colocar los modelos crea- 
dos por el usuario sin peligro de que es- 
tos interfieran con los objetos celestes. 
Naturalmente este volumen interior 
puede resultarnos algo pequeño en 
ciertos casos y por ello Colefax nos 
ofrece la posibilidad de ampliarlo alte- 
rando el valor de una variable. 

Aunque teóricamente podemos crear 
objetos de cualquier tamaño en «POV», 
en la práctica pueden darse cuelgues 
del programa al intentar trabajar con 
objetos muy grandes. Además, la velo- 
cidad del render puede ralentizarse a 
medida que aumenta el volumen espa- 
cial a tratar. Por esta razón los objetos 
creados por este POV-IPAS son relati- 
vamente pequeños y puede darse el caso 
de que una de nuestras naves espaciales 
tenga unas dimensiones superiores a 
las de las estrellas y galaxias creadas 
por el paquete. 

Pero veamos qué posibilidades nos 
ofrece este POV-IPAS. El paquete está 
formado por cuatro ficheros: galaxy.inc, 
galaxy.bg, galaxy.obj y galaxy.sf. Y el 
sistema que conforman está diseñado 
para ofrecer diferentes posibilidades de 
empleo al usuario. 

La primera opción (y la más simple) 
es limitarse a invocar al archivo ga- 
laxy.inc, el cual incluirá a los ficheros 
restantes y pasará valores a algunas de 
sus variables para crear un paisaje este- 
lar; cuyo,aspectu dependerá del valor 
de semilla que hayamos especificado 
conla variable galaxy_seed. 

La siguiente posibilidad es realizar 
cambios manuales sobre los resultados 
obtenidos con un paisaje aleatorio, y la 
última es desechar el uso de galaxy.inc 


Aquí tenéis aigunos ejempios de los fondos que pueden generarse con 


Gaiaxy.inc. 


y crear un paisaje estelar a medida. Pa- 
ra ello el usuario habrá de decidir pri- 
mero qué objetos desea incluir en su 
fondo estelar y luego experimentará 
con diversas variables antes de invocar 
a alguno de los restantes ficheros del 
paquete (o a todos). 


La opción más simple 

Podemos generar nuestro primer 
fondo estelar simplemente incluyendo 
las dos líneas siguientes en nuestro fi- 
chero escénico! 
ttdeclare galaxy_seed = 123456789 
ttinclude “GALAXY.INC* 

La variable galaxy_seed es la semi- 
lla para el generador de números pseu- 
doaleatorios. Cada valor diferente da- 
do.a.la semilla producirá un fondo 
estelar diferente. Galaxy.inc presupo- 
ne que el centro de la esfera-toldo está 
en las coordenadas <0,0,0> y también 
supone que la cámara se halla situada 
en la misma posición y que está enfo- 
cada mirando a lo largo del eje Z, en 


la dirección negativa de éste. Es nece- 
sario recordar esto porque, por defec- 
to, este archivo genera los objetos ce- 
lestes más interesantes (los racimos de 
estrellas, las nebulosas cercanas, los 
cometas, etc.) teniendo estu en cuenta. 
Así, si hacemos rotar a la cámara para 
que apunte en otra dirección, seguire- 
mos viendo un fondo estelar, pero la 
escena resultante será mucho menos 
espectacular. 

Ahora comencemos a hacer experi- 
mentos con algunas de las variables 
del paquete. Tanto el funcionamiento 
de Galaxy.inc como el del resto de los 
archivos del paquete puede ser contro- 
lado dando valores a ciertos variables 
de control. Naturalmente estos valores 
han de ser escritos antes de la senten- 
cia include que carga el fichero co- 
rrespondiente donde las variables pro- 
ducen su efecto. Veamos por ejemplo 
cómo cambiar las dimensiones de la 
esfera-toldo: 

Htdeclare galaxy_distance=20000 
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Nuestro primer experimento (en pruebas.pov). 


Aquí manipulamos a ¡as estrelias dei piano de fondo. 


La línea precedente dobla el valor 
que por defecto galaxy.inc asigna al 
diámetro de la esfera-toldo pero, si in- 
cluimos esta línea en el ejemplo prece- 
dente, el fondo estelar que obtendre- 
mos será el mismo. Esto se debe a que 
galaxy.inc volverá a escalar todos los 
objetos estelares para que conserven el 
tamaño relativo asignado por defecto. 
El único cambio estará en que ahora 
dispondremos de un volumen espacial 
mucho mayor para situar nuestras na- 
ves (o lo que sea) en la escena, puesto 
que el diámetro de la esfera se ha do- 
blado. Sin embargo, hay que tener cui- 
dado con esto, debido a la posible len- 
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En nuestro segundo experimento añadlmos un 
racimo de estrellas cercanas. 


5 


AL 


titud del render, de modo que quizá nos 
resulte más práctico empequeñecer la 
escala de nuestros modelos en lugar de 
aumentar el tamaño de la esfera. 

En cuanto a las demás variables de 
galaxy.inc, podemos comentar que Ga- 
laxy.colour se emplea para alterar las 
intensidades de color RGB de la esce- 
na. Estas variaciones no son absolutas 
sino que se efectúan sobre los valores 
de color que el generador ha asignado 
ya a la escena. Veamos un ejemplo: 
ftdeclare galaxy_colour=<1.5, 1, 0,5> 

Esta línea hace que aumente la in- 
tensidad del componente rojo de la es- 
cena, deja el verde sin cambiar y redu- 


Trasteando con las variables de la nebuiosa. 


ce la fuerza del azul. (Nota: Colefax 
emplea realmente un doble juego de 
variables con el fin de soportar la ver- 
sión inglesa y la americana de algunas 
palabras. Así, por ejemplo. podemos 
emplear galaxy_color en lugar de la va- 
riable del ejemplo o galaxy_coloration 
en lugar de galaxy_colouration). 
Probablemente nos resultará difícil 
anticipar los resultados del uso de ga- 
laxy_color pero afortunadamente Co- 
lefax ha preparado otras variables cu- 
yo manejo nos resultará más intuitivo. 
Una de ellas es galaxy_coloration, que 
sirve para incrementar o reducir la in- 
tensidad del color del fondo estelar res- 


petando el tono básico. Así, la línea... 
Fdeclare galaxy_coloration=1.2 
...Intensifica el tono del fondo, sea 
cual sea, produciendo una escena con 
colores más vivos. Los valores inferio- 
res a | producen el resultado opuesto. 
Otra variable muy interesante €es ga- 
laxy_intensity, que nos servirá para au- 
mentar o reducir el grado de transpa- 
rencia de la nebulosa estelar con 
respecto al fondo de estrellas que se en- 
cuentra detrás de dicha nebulosa. Esta 
variable requiere, como la anterior, un 
valor en flotante y su valor por defecto 
es de 1. Aquí tenéis un ejemplo: 
Htdeclare galaxy_intensity=1.5 
Esta línea aumenta la opacidad de la 
nebulosa. También puede resultarnos 
interesante la posibilidad de mover el 
fondo estelar sin cambiar la cámara 
(que de esta manera seguirá enfocando 
a las posibles naves que existan en el 
primer plano). Esto podremos lograrlo 
utilizando la variable galaxy_rotate a la 


que daremos un vector donde se indi- 
carán los grados de rotación para cada 
eje. Así, con la línea siguiente... 
declare galaxy_rotate= <30,90,0> 

.-«€l fondo estelar rotará 30 grados en 
el eje X y 90 en el Y. 


Los otros ficheros 

El archivo galaxy.inc no hace sino 
dar valores a ciertas variables de otros 
ficheros del paquete antes de incluir a 
éstos para crear las escenas. Podemos 
pues prescindir de galaxy.inc, asignar 
directamente los valores precisos a las 
variables convenientes e incluir direc- 
tamente a uno o a todos los ficheros 
restantes del paquete en nuestro archi- 
vo de escena. Veamos qué hacen estos 
archivos. 

Galaxy.bg está encargado de crear la 
nebulosa estelar de fondo que suele 
formar parte de la mayoría de las esce- 
nas que generaremos. Galaxy.sf se em- 
plea para crear la capa de estrellas de 


Preparando la conversión a POV del fabuloso caza modeiado por Mark 
Kane. 


3 tamaño mediano (galaxy.bg añade tam- 


bién estrellas que se reducen a simples 
puntos para aparentar una mayor leja- 
nía). Por último, galaxy.obj es el fiche- 
ro encargado de crear los objetos este- 
lares situados en primer plano. (Nota: 
los objetos de galaxy.obj serán los que 
perderemos de vista si cambiamos la 
orientación de la cámara). 

Ahora vamos a comenzar a trastear 
con estos archivos, pero realizaremos 
nuestros experimentos sobre escenas 
completas generadas con galaxy.inc, 
con el objetivo de apreciar mejor cómo 
afectan nuestras pruebas al conjunto. 
Para ello podéis echar un vistazo al fi- 
chero pruebas.pov, donde hemos guar- 
dado una pequeña lista de pruebas. Para 
generar alguna de estas pruebas, elimi- 
nad los caracteres “/*” y “*” que defi- 
nen el bloque de líneas de cada experi- 
mento como comentarios. Para probar 
otro experimento volved a marcar el 
bloque anterior como comentario —para 
anular su procesamiento por parte de 
POV- y quitad las marcas-comentario 
del experimento que deseéis probar. Por 
supuesto, también podéis añadir aquí 
vuestros propios experimentos. Estudie- 
mos el caso del primer experimento: 


(“experimento 1”) 


itdeclare galaxy_seed = 8563461 
Stdeclare options_only = true 
Hdeclare debug_options=true 
ftinclude “GALAXY.INC” 


// Experimento num. 1 


Fdeclare galaxy_object_name="Star1” 
Htinclude “GALAXY.OBJ” 

Htinclude “GALAXY.BG” 

Htinclude “GALAXY.SF” 
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En este experimento la línea que 
asigna el valor true a la variable op- 
part te. Al 
incluirla, el usuario le estará pidien- 


tions_only es muy * 


do a galaxy.inc que anule la inclu- 
sión de los ficheros galaxy.obj, ga- 
laxy.bg y galaxy.sf, pero todo lo 
demás seguirá funcionando igual. 
Esto quiere decir que galaxy.inc pre- 
parara las variables necesarias para 
los demás ficheros para crear una es- 
cena aleatoria, pero tendrá que ser el 
usuario quien escriba los includes 
necesarios para cargar a galaxy.obj, 
galaxy.bg y galaxy.sf. 

Esto deja abierta la posibilidad de 
que cambiemos algunas de las varia- 
bles definidas por galaxy.inc para es- 
tos archivos, lo que tendrá como 
consecuencia ciertos cambios con 
respecto a la escena final que ga- 
laxy.inc generaría con la semilla que 
le hayamos asignado. Esto convierte 
a options_only en una de las varia- 
bles más importantes creadas por 
Colefax, puesto que su uso nos per- 
mitirá comprobar cómo afecta cada 
cambio a una escena válida genera- 
da por el paquete, como deseábamos 
hacer. 

En cuanto a debug_options, al asig- 
narle el valor true estaremos pidiendo 
a galaxy.inc que imprima en pantalla 
los valores asignados a las variables 
de construcción del fondo estelar. 
Con ello podremos tomar nota de las 
variables que se van a tratar con un 
valor determinado de semilla y podre- 
mos crear nuestras modificaciones 
mas fácilmente. 

Nota: Colefax utiliza la sentencia 
tídebug del lenguaje escénico de 
«POV>» para imprimir textos en panta- 
lla y los valores de sus variables. 
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Experimentos 

Para el primer experimento nos he- 
mos limitado 4 añadir una estrella del 
tipo 1. Pero esta estrella no es la única 
protagonista de la imagen puesto que 
también aparecen cuatro meteoros en 
el centro de la misma. Estos meteoros 
han sido creados por galaxy.inc, que 
siempre intenta crear unos objetos del 
tipo “primer plano” para realzar las 
escenas. La colocación de estos obje- 
tos puede llevarse a cabo de dos ma- 
neras: podemos emplear la variable 
galaxy_object_name, con la que podre- 
mos situar uno de estos objetos en la 
imagen, o bien podemos utilizar la va- 
riable galaxy_cluster_name, con la que 
se dibujará un grupo de cuerpos celes- 
tes (cluster=grupo o racimo). 

En el ejemplo, galaxy.inc ha utili- 
zado galaxy_cluster_name a la que 
ha asignado el nombre “Meteorl” 
mientras que nosotros hemos utiliza- 
do galaxy_object_name con el nom- 
bre “Starl”. Estos nombres se han to- 
mado de la lista de objetos celestes de 
primer plano que ha creado Coletax. 
En esta lista el nombre para cada tipo 
de objeto se forma añadiendo un nú- 
mero al nombre de la clase a la que per- 
tenece. La familia de las estrellas se lla- 
ma “Star” y consta de cuatro tipos 
diferentes de estrellas (es decir, que los 
miembros son Starl. Star2. Star3 y 
Star4). También hay una clase de nebu- 
losas (“Nebula”) que tiene seis miem- 
bros, otra de galaxias (“galaxy”) que 
consta de cinco elementos, otra de co- 
metas (“Comet”) que tiene tres miem- 
bros y una de meteoros (“Meteor”) de 
la que hay dos tipos. 

Todos los objetos de “primer plano” 
se colocan por defecto en el centro de 
la escena, lo que puede acabar recar- 


gando la imagen si no hacemos algo. 


Podríamos, por ejemplo, eliminar a los 
meteoros de la escena. 

Para ello sólo tendríamos que incluir la 
línea “declare galaxy_cluster_name=”. 
Esto le diría a galaxy.obj que no hay 
ningún grupo de objetos de primer pla- 
no en la escena. (El mismo truco vale 
para galaxy_object_name). 

También podríamos crear varios 
objetos sueltos o varios grupos de 
ellos pero alterando su colocación en 
la escena. Esto podemos hacerlo utili- 
zando la variable galaxy_object_po- 
sition que se emplea para cambiar la 
colocación de los objetos individua- 
les y de los grupos de objetos (elus- 
ter) en la esfera-toldo. La variable re- 
quiere la asignación de un vector en 
el que se emplean los valores dados 
en grados a los ejes X e Y para des- 
plazar al objeto a cualquier nueva po- 


sición en la esfera-toldo (el compo- 
nente de Z es ignorado). Esto signifi- 
ca que si aplicamos al experimento 
anterior la siguiente línea... 
ttdeclare galaxy object_position=<0,180,0> 
...tanto la estrella como los meteoros 
desaparecerán de la escena y tendre- 
mos que hacer rotar la cámara 180 gra- 
dos en X o Y para volver a verlos. 
Otra variable a tener en cuenta es 
galaxy_object_rotate. Esta variable 
se emplea para hacer girar los obje- 
tos a lo largo del eje de visión Z y por 
tanto no necesita un vector, sino sólo 
un valor en flotante para indicar los 
grados deseados. La emplearemos 
para que los objetos celestes no que- 
den demasiado alineados en la esce- 
na. Para comprobar bien su funciona- 
miento lo mejor es emplear un objeto 
grande y bien definido, como alguna 
galaxia. 


El aspecto de los objetos 
Aunque el acabado de los cuerpos 


celestes diseñados por Colefax es fan- 
tástico, los resultados pueden no ser 
tan buenos con ciertos colores o em- 
pleando una escala mayor. Esto es fácil 
de apreciar haciendo pruebas con la 
variable galaxy_object_scale. Esta va- 
riable sólo necesita un valor en flotan 
te ya que el cambio de escala es uni- 
forme en todos los ejes (un valor de 2 
dobla el tamaño del objeto mientras 
que otro de 0.5 lo reduce a la mitad). 
Si escalamos un objeto como Galaxy 1 
el resultado será bastante bueno. inclu- 
so aunque hagamos al objeto tres veces 
más grande, pero esta misma prueba 
resultará desastrosa utilizando Galaxy5, 
que, sin embargo, queda bien con la es- 
cala 1 empleada por defecto. 

Otra variable que podemos emplear 
para cambiar el acabado de los obje- 


tos es galaxy_object_flatten, a la que 
daremos un valor en flotante que ser- 
virá para aplanar o ensanchar la forma 
de los objetos. Para comprobar cómo 
funciona tendréis que renderizar una 
escena con el objeto Galaxy1 y luego 
volver a realizar la prueba añadiendo 
la línea: 
ftdeclare galaxy_object_flatten=0.8 

Esto hará que la galaxia parezca es- 
tar más inclinada con respecto al es- 
pectador. El valor dado por defecto es 
0.2. Con un valor de O no hay aplana- 
miento mientras que con otro de 1 el 
objeto quedará totalmente aplanado. 
Finalmente, otro punto a tener en cuen- 
ta es que no todos los objetos quedan 
bien como grupos. Esto resultará vi- 
sualmente adecuado en el caso de es- 
trellas y meteoros, pero no en el de ga- 
laxias y nebulosas. 


Grupos de objetos de 
primer plano 

Ahora tomad nota de las variables 
que controlan a los objetos cluster. En 
primer lugar tenemos a galaxy_clus- 
ter_objects, a la que asignaremos un 
valor con el número de los objetos que 
van a formar parte del grupo a crear. 
También podemos usar galaxy_clus- 
ter_scale (que requiere un valor en flo- 
tante) para aumentar o disminuir el ta- 
maño de los objetos individuales que 
componen al cluster. Otra variable in- 
teresante es galaxy_scale_turb, a la que 
daremos un valor en flotante para au- 
mentar o disminuir las diferencias de 
tamaño entre los objetos que compo- 
nen el cluster. Asignando un valor de 
0, todos los objetos del cluster tendrán 
el mismo tamaño mientras que con 1 
las diferencias de tamaño serán bastan- 
te extremas (el valor dado por defecto a 
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AA, 


esta variable es de 
0.5). Colefax ha pen- 
sado incluso en una 
variable para evitar la 
excesiva simetría en 
los brillos de los gru- 
pos de estrellas. En es- 
tos casos podremos 
emplear a galaxy_ro- 
tate_turb para variar 
aleatoriamente la rota- 
ción (en el eje Z) de 
las estrellas del gru- 
po. Para ello asigna- 
remos a esta variable 
un valor en flotante 
que oscilará de O a 360, consiguiendo 
en este último caso una variación alea- 
toria de entre O y 360 grados para cada 
una de las estrellas del grupo. Nota: 
creemos que en este caso la uniformi- 
dad es mejor. 

Por último, puede interesarnos cam- 
biar las distancias entre los componen- 
tes del grupo. En este caso empleare- 
mos la variable galaxy_cluster_spread 
a la que asignaremos un valor en gra- 
dos que variará de O a 360. El valor da- 
do por defecto es de 15. Con un valor 
de 360 los componentes del grupo se 
esparcirán por todo el cielo. Nota: en el 
experimento 2 tenéis pruebas de todas 
estas variables. 


El fondo estelar 

Tampoco debemos descuidar el 
campo estelar de medio fondo. Tomad 
nota del uso de las siguientes variables 
(experimento 3): 

star_count: Es el contador de estrellas. 

star_colour: Es el color de las estre- 
llas. El valor RGB por defecto es <0.9, 
0.9, 0.9>. 

star_type: Usaremos el valor 1, 26 
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La liamarada de ¡os cohetes está hecha con un par de halos. 


3 para elegir el tipo de las estrellas. 

star_scale: Esta variable sirve para 
fijar el tamaño medio de las estrellas de 
fondo. El valor dado por defecto es de 
| pero probablemente tendremos que 
cambiarlo dependiendo de la resolu- 
ción con la que estemos trabajando. 
(Un valor de 0.5 reduce a la mitad el ta- 
maño medio y un valor de 2 lo dobla). 

star_distance: realmente no hay una 
sola esfera-toldo sino dos: una para la 
nebulosa de fondo y otra para el fondo 
estelar. El diámetro de esta última se fi- 
ja con star_distance que por defecto es- 
tá a 20000. 


La nebulosa 

Por último, aquí tenéis unas notas 
sobre algunas de las variables que con- 
trolan la nebulosa de fondo: 

galaxy_bgnebula: con esta opción 
indicaremos, utilizando un valor entre 
l y 6, el tipo de pigmento que desea- 
mos para la nebulosa de fondo. Si no 
se desea una nebulosa de fondo hay 
que poner esta variable a “false”. 

galaxy_nebula_ambient: emplea 
un vector (que por defecto es <1,1,1>) 


para cambiar el valor 
de la luz ambiente de 
la nebulosa. 

galaxy_colourl, 2 y 3: 
únicamente necesita- 
remos dar un valor pa- 
ra galaxy_colourl si 
queremos crear una 
nebulosa de un solo 
color. Con las otras 
dos variables podre- 
mos añadir dos colo- 
res base más pero el 
resultado puede ser 
bastante confuso. 

galaxy_patter_scale: 
esta variable, que por defecto está al 
valor 1, nos servirá para escalar la tra- 
ma de la nebulosa sin cambiar su for- 
ma básica. 


Notas: 

*Existen tres variables que se em- 
plean para desactivar la creación de 
los objetos que generan los ficheros 
galaxy.bg, galaxy.sf y galaxy-ob]. 

Estas variables son, respectivamen- 
te, galaxy_bg, galaxy_starfield y ga- 
laxy_objects. Para eliminar de la es- 
cena a los objetos que crean los 
archivos a los que se refieren, basta 
con ponerlas a false. Estas variables 
son puestas a false automáticamente 
siempre que se incluye un galaxy.inc, 
por tanto habrá que ponerlas a true 
antes de invocar a galaxy.inc otra vez 
dentro del archivo escénico. 

Aún falta por añadir un último deta- 
lle, la iluminación. Tenéis que recordar 
añadir las luces necesarias para ilumi- 
nar a los modelos propios que añadáis a 
la escena. Si no lo hacéis así vuestros 
objetos sólo serán sombras recortadas 
contra el fondo estelar. 


ns 


El Foro del Lector 


Noia importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en el sumario de Pcmonía, o vía e-mail a rendermania.pecmania Q hobbypress.es 


Poesía en imágenes 


Una de las ventajas que posee la publicación, en un mismo espacio, de 
un conjunto de imágenes es la variedad. Una variedad que afecta 

no sólo a los programas empleados para su realización o a los temas 
tratados, sino también al propio estilo que impregnan las imágenes. 

En efecto, las obras que incluimos en esta sección desprenden 
fantasía, sentido del humor e incluso poesía. 


Quienes contemplen las escenas de este autor ya se habrán dado cuenta 
que la palabra poesía se refería a la obra de ¿1mgel Lanza Salcimes. 


Ángel, quizá algo abrumado por los elogios (merecidos) que le dedicamos 


en el número 14, asegura que aún tiene que progresar mucho. Es posible, 
desde luego, pero —con independencia de tu nivel técnico (que no nos pare- 
ce nada desdeñable)- creemos que tus escenas son extraordinarias por la 
magia y belleza que transmiten. Por nuestra parte te agradecemos tus elo- 
gios pero lo que más nos ha emocionado es la escena Jmm.jpg. donde Pa- 
mela posa con algunos de nuestros viejos modelos. ¡Gracias! En cuanto a 
tus opiniones sobre el arte en general y la infografía en particular nos han 
parecido interesantes y queremos animar al resto de los lectores a que enví- 
en sus propias opiniones sobre estos y otros temas. Para dar ejemplo ahí va la nuestra: cualquier soporte de información 
puede ser un medio válido para crear arte. El arte, la magia, la poesía, pueden estar en una escena sintética, en una par- 
tida de ajedrez, en un programa, en un libro, en un cómic e incluso en una demostración matemática. Pero todo de- 
penderá de lo que el artista consiga plasmar en su obra. Por otra parte, creemos que muchos de los trabajos que se acep- 
tan hoy como arte no son más que tomaduras de pelo o especulaciones comerciales. En fin, en esta ocasión tenemos dos 
cartas de Ángel (la segunda está en el 
directorio salcinestotra). En una de 
ellas las escenas están montadas en 
una página HTML y en la otra tene- 
mos una resultona animación en la 
que aparece otra de las impresionan- 
tes chicas de Ángel y de la que se ad- 
junta un divertido “making of”. 
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José Luis García Fuertes es un povma- 
níaco a la vieja usanza. Los modelos que 
nos envía han sido creados con el lenguaje 
escénico de «POV» y renderizados con él. 
Deseando participar en la escena de Mechs, Jose Luis nos envía un bo- 
nito y original aparato parcialmente articulable desde «POV». Si has le- 
ído los últimos números de Rendermanía ya habrás visto que no es tan 
difícil crear piernas y brazos articulables. 

No te preocupes, tu modelo aparecerá en la próxima portada de Mechs y 
lo mismo podemos decirte del precioso submarino que has preparado 


para los orcos, que intervendrá en la próxima batalla donde éstos parti- 
| cipen. Es decir, lo incluiremos si nos envías el modelo, porque te has olvidado de incluirlo en el disquete. Por cierto, 
| el diseño del submarino es muy gracioso pero ¿se puede abrir la escotilla trasera para que el comandante asome la ca- 

bezota? Y en ese caso, ¿la escotilla no debería estar en otro sitio para que la torreta no obstruya la visión? 


Julián Hortolano Villareje nos envía un escritorio virtual y tiene va- 


rias dudas que intentaremos aclarar: «POV>» es un programa de orien- 
tación distinta a la de «Spatch». Este último es un modelador que sólo 
dispone de un pequeño render de trabajo mientras que «POV>» tiene un 
render de gran calidad. pero no una interfaz gráfica para crear modelos. 
Por otra parte, para crear escenas de calidad tendrás que exportar tu 


Luis Martin Manguero nos pide 
una crítica de las imágenes que ha 


preparado utilizando «3D Studio». 


Bien, tus escenas tienen una buena 
iluminación aunque las sombras te 


modelo a «POV» y renderizarlo desde este programa. Esto puedes ha- han quedado. 


cerlo de varias maneras: exportando el modelo directamente a «POV» quizá, dema- 
—en Cuyo caso éste se grabará como patches bicúbicos (un objeto de siado difusas 
«POV»)., o bien grabarlo como DXF y reconvertir este formato con al- (en el caso del 
guna utilidad para que «POV» pueda leerlo. La lentitud de redibujado despertador). 
de «Spacth» se debe a que los puntos que maneja son puntos de control En una de las 
de splines. Las formas generadas con splines requieren más cálculos entradas de la 
que las típicas formas poligonales, pero si te lo montas bien emplearás sala de baños 

la textura de ladrillos se te ha corrido 
(deberías haber dividido la aplica- 


ción). Además, sucede algo raro en 


muy pocos puntos. (Nosotros pondríamos más RAM en tu ordenador 


aunque probablemente 
esto no afectará a la ve- 
locidad de redibujado 
de «Spatch»). Y sí, ha- 
brías podido hacer la 


estas entradas. La escena que más 
nos ha gustado ha sido la del desper- 
tador, por su sentido del humor. 
misma escena con bas- 
tantes menos puntos de 
control, pero este es un 
defecto que cometemos 
todos alguna vez. 
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José Antonio 
Aroca nos envía 
varias escenas 
espaciales crea- 
das con «Cali- 
gary Truespace». 
Entre ellas nues- 
tra favorita es “objetivo” que está sacada de una viñeta 


de Tintín y que nos parece la más conseguida (aunque 


es una pena que 
no hayas podido 
emplear los halos 
de «POV» para la 
llamarada del co- 
hete). Esperamos 
volver a verte 
pronto por aquí. 


Alberto y Oscar Otero Leal nos envían una divertida 


animación realizada con «MAX» en la que intervienen un 
búho y una rata. Según cuenta Oscar, esperaban conse- 
guir un look parecido al de las tiras de algunos periódicos 
y..- lo han logrado. 
Los modelos de 
los personajes son 
sencillos. pero es- 
to se debe al pro- 
pio diseño planea- 
do en papel para 
los mismos y no a 
una falta de cono- 
cimientos. En su 


carta Oscar nos 


cuenta los pormenores de la construcción de ambos mode- 
los e incluye detalles acerca de los sonidos que han puesto 


a la animación. Enhorabuena a ambos por vuestro trabajo. 


4lain 5. Bañuls Vilela es otro 
povmaníaco que nos envía un par 
de mechs que aparecerán en la 
próxima portada sobre mechas. 
Alain también nos envía su último 
trabajo: una reconstrucción de la 
Punta de la Barca (Muxia. La Co- 
ruña). Esta escena ha sido cons- 
truida con «POV», aunque el au- 


tor también se ha apoyado en 
«Spatch» (hemos eliminado los ficheros a petición del au- 
tor), y todavía no está completa del todo ya que Alain aún 
está luchando con las rocas de la playa. Echamos en falta al- Gonzalo Blazquez ha conseguido crear una escena 
gún pov-ipas que cree escenarios de terreno para planos cer- desértica de gran realismo utilizando «3D Studio» 
canos de rocas, desfiladeros, playas, etc. Nos han gustado y algunos programas de retoque fotográficos. Y es 
mucho tus mechas. El anfibio de desembarco tiene una for- que este auror ha puesto “a mano” detalles como 
ma muy original, parece un cangrejo. y el otro es muy gra- los reflejos del sol en el erisial delantero y las som- 
cioso. ¿Qué programa has empleado para hacerlos? ¿Y por bras (así como el soldado del fondo). En definitiva. 
qué no los has preparado una gran escena llena de detalles con texturas bien 
para que se articulen des- 
de« POV»? Gracias por 


tu contribución a la arti- 


aplicadas y un modelo estupendo a pesar de su re- 


lativa simplicidad. Pero; ¿por qué la escena tiene 


tanto granulado? Y por favor. la próxima vez envía 


llería pesada mecha. la carta como fichero. 
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Roberta Font Rus. nos envía varias escenas y animacio- 
nes que esián muy bien teniendo en cuenta la poca expe- 
riencia infográfica de este autor. Entre ellas figura una ani- 
mación creada con la idea de responder al reto del combate 
de magos que proponía Juan B. Garraza Zurbano. En dicha 
animación un mago-caballero camina y lanza una bola ener- 
gética. ¿Cómo arbitrar éste u otros futuros combates? Lo 
ideal sería que ambos contendientes apareciesen en la mis- 


ma animación, pero esto sería bastante difícil por razones 

obvias. Por tanto proponemos lo siguiente: 

1) Un autor publica una escena o animación acerca de mechs, brujos. chicas o lo que sea y lanza un reto. 

2) Las animaciones de las que hablamos aquí no deberán exceder los 5 Megas comprimidas. 

3) Alguien recoge el guante publicando la respuesta con una escena o animación, dependiendo de lo que haya exigi- 
do el retador, de su propio modelo. 

4) Los lectores disponen de tres meses. a partir del momento en que se publica la respuesta, para votar en el foro. 

5) El ganador tendrá derecho a publicar una escena o animación de victoria mientras que el perdedor, si es un buen de- 
portista, estará obligado a enviar una escena o animación en la que se ilustre su derrota. Estos trabajos deberán en- 
viarse antes de que se cumplan cuatro meses después de la publicación del fallo. 

6) El perdedor tendrá la posibilidad de obtener la revancha. entendiéndose que el combate se producirá contra el últi- 
mo trabajo del mismo tipo que haya publicado mientras tanto el retador. Esto no evitará al perdedor el cumplimiento 

de la cláusula anterior. En este caso la votación podrá empezar con la pu- 

blicación del nuevo trabajo del derrotado. 

7) La recogida del guante supone la aceptación de todas las condiciones 
anteriores so pena de escarnio público. 

Naturalmente, estos combates pueden ser múltiples si más de un lector 

recoge el guante en un mismo número de Rendermanía. Además. si la 

idea tiene éxito podríamos mejorarla... ¿Qué decís? ¿Quién se anima? 

En cuanto al trabajo de Roberto, está hecho con «3D Studio» y «MAX». Las 

escenas no están mal aunque nos han gustado más las animaciones. De tus 

escenas, la espacial cuyos fondos has generado con «MAX» es nuestra pre- 


ferida. ¿Qué opinas de los fondos que crea el Pov-ipas de Colefax? 


Lranoece Joss Serrano Res ha sufrido lo suyo para utilizar 
un paisaje de HF-lab con «3D Studio 4», por lo que la lectura de 
su carta puede ahorrar sufrimientos inútiles a quienes planeen 
hacer algo parecido. Francisco deseaba un buen paisaje de fon- 


vo Ho a A 0 


do para la escena donde exhibe su Mech Marauder. Pero lo cier- 


to es que la posición de la cámara, lógicamente centrada en el 


Lo h r 


Marauder, no permite captar demasiados detalles del fondo 


montañoso. En cuanto al Mech de la escena, es una buena re- 
creación del Mad-3R Marauder de Battletech. Bien, Francisco, 
en nombre de todos: gracias por tus notas sobre H£lab. 
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